Smart cards are becoming increasingly more popular for security and personal identification applications. For example, smart cards are currently used for storing sensitive data such as medical records, banking information, and similar data requirements. In perhaps their most common form, smart cards have a card body that resembles a credit card in size, shape, and thickness, and may be made out of similar materials, for example, plastic. Rather than having a magnetic stripe to store sensitive information (e.g., account numbers, user identification, etc.) as standard credit cards do, smart cards generally include an integrated circuit (IC). The IC not only includes a non-volatile memory for storing sensitive data, but it may also include a microprocessor for processing this data and communicating with a host device via a card reader, for example. Not only can smart cards store more information than magnetic stripe cards, but also they have much greater functionality.
Various protocols have emerged to standardize the operation and communications of devices such as smart cards. One of the earliest of these was developed by the International Organization for Standardization (ISO) and is known as the ISO 7816-X protocol. In particular, this protocol is set forth in ISO documents ISO 7816-1 (Physical Characteristics), ISO 7816-2 (Dimensions and Locations of Contacts), ISO 7816-3 (Electronic Signals and Transmission Protocols), ISO 7816-10 (Electronic Signals and Answer to Reset for Synchronous Cards), and ISO 7816-12 (USB Interface) for example, all of which are hereby incorporated herein in their entirety by reference.
Furthermore, in response to the increasing popularity of the universal serial bus (USB) architecture, increasing numbers of smart cards continue to be developed which operate in accordance with the USB protocol. This protocol is set forth in the Universal Serial Bus Specification, Revision 2.0, Apr. 27, 2000, published by USB Implementers Forum, Inc., which is hereby incorporated herein in its entirety by reference. The USB architecture is particularly advantageous because it provides a standard “plug and play” interface for devices external to a computer, for example. External peripheral devices can be relatively quickly and easily installed and removed from a host device, e.g., a computer, without having to reboot or power down the computer.
Most product development cycles for complex computing systems or devices require a functional equivalent of the product before the final product is available. This functional equivalent is typically referred to as an emulator, or hardware emulator (HWE). The HWE allows the application developers for the product to develop and debug software applications for the device while the product engineers finalize and test the physical circuitry and/or components of the product.
With respect to smart cards, a HWE emulator is commonly used to develop, test, and debug new applications which will ultimately become embedded in the final smart card integrated circuit. The HWE should provide functionality that matches as closely as possible the real-world functionality of the end product (e.g., a smart card integrated circuit). This emulation should also be applicable to complicated dual-mode smart cards, such as dual ISO/USB smart cards. One such dual mode smart card is described in U.S. Pat. No. 6,439,464 to Fruhauf et al., assigned to the assignee of the present invention, and which is hereby incorporated herein in its entirety by reference.
Electronic Design Automation (EDA) software tools are often used to simulate a smart card (or other) chip design prior to prototyping or production. Designers often use a Hardware Description Language (HDL), such as Verilog® or VHDL, to define functional components and decompose them into smaller components. Software routines are placed and routed into logic cells at specific coordinate locations in a circuit layout.
Functional blocks, also called virtual component (VC) blocks, virtual components, or IP blocks, are often used by designers as pre-designed circuit functions. In many cases, these functional blocks are pre-hardened or semi-hardened circuit designs in software form that are re-used or recycled into larger circuit designs. The use of virtual component blocks reduces overall circuit design time and increases the speed a final design can reach market. These functional blocks as virtual components can also be pre-tested and verified from logical and functional standpoints.
Emulators often use functional blocks and a baseline architecture with the Virtual Socket Interface (VSI) for any “system-on-a-chip” (SoC) solution. Some functional blocks are specifically designed for use with a particular IC, and other functional blocks had been designed for use with other IC's and obtained from internal and/or external sources.
The Virtual Socket Interface (VSI) Alliance™ Architecture Document Version 1.0, the disclosure which is hereby incorporated by reference in its entirety, specifies the hardware and software interfaces, formats and design practices for creating functional blocks to enable efficient and accurate integration, verification and testing of multiple blocks on a single piece of silicon. The VSI standard is operative with an HDL description to allow IC design to be done using a component based solution. Virtual components as functional blocks are used in the design environment, and more particularly, a virtual socket design environment. Typically, virtual components can be soft, firm or hard. Usually a virtual component is a functional block designed to a set of specifications having an output that is a standard format with a pre-defined set of characteristics to simplify integration and verification.
As noted before, smart card integrated circuits as designed for preferred USB smart card devices (USD) require a design for a functionally equivalent representative well in advance of the final silicon product. It is expected that any emulated version will not necessarily work at the same clock rate of the final silicon. Due to the nature of today's emulation tools and environments, however, it is possible to emulate complete products only at a mere fraction of their silicon form. This, of course, is dependent on the nature and complexity of the design, and the capability of the emulation tools to implement the design into the resources of the emulator.
For example, an emulator which uses large arrays of Field Programmable Gate Array (FPGA) devices into which the target HDL design is implemented, may be capable of operating at only a few hundred kilohertz (KHz), predominantly at the digital portions of the design. Analog portions must usually be implemented in functionally equivalent “attachments” to the main emulator.
Even custom designed emulator packages suffer similar problems. For situations where an interface to the outside world must function at real world speeds in order to be useful, this poses technical challenges. One drawback occurs when top level functional blocks or sub-blocks or virtual sub-components, must be emulated, but must also function in their own clock domains. These domains are typically separated by a wide margin in emulation for various reasons, but this margin is manageable in the final at-speed silicon product. For emulation purposes, the top level design does not work.
Usually, the design must be modified, which also increases the risk, however, of emulating a design which is not faithful to the original design. Thus, there are now two different designs: (1) a first design will go to fabrication; and (2) a second design will go to an emulator, and as a result, may be delivered to a key customer for early development work.